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Abstract 


In recent years. Software Transactional Memory systems (STMs) have garnered significant in¬ 
terest as an elegant alternative for addressing concurrency issues in memory. STM systems take op¬ 
timistic approach. Multiple transactions are allowed to execute concurrently. On completion, each 
transaction is validated and if any inconsistency is observed it is aborted. Otherwise it is allowed to 
commit. 

In databases a class of histories called as conflict-serializability (CSR) based on the notion of 
conflicts have been identified, whose membership can be efficiently verified. As a result, CSR is the 
commonly used correctness criterion in databases In fact all known single-version schedulers known 
for databases are a subset of CSR. Similarly, using the notion of conflicts, a correctness criterion, 
conflict-opacity (co-opacity) which is a sub-class of can be designed whose membership can be 
verified in polynomial time. Using the verification mechanism, an efficient STM implementation 
can be designed that is permissive w.r.t co-opacity. Further, many STM implementations have been 
developed that using the notion of conflicts. 

By storing multiple versions for each transaction object, multi-version STMs provide more con¬ 
currency than single-version STMs. But the main drawback of co-opacity is that it does not admit 
histories that are uses multiple versions. This has motivated us to develop a new conflict notions for 
multi-version STMs. In this paper, we present a new conflict notion multi-version conflict. Using 
this conflict notion, we identify a new subclass of opacity, mvc-opacity that admits multi-versioned 
histories and whose membership can be verified in polynomial time. We show that co-opacity is a 
proper subset of this class. 

An important requirement that arises while building a multi-version STM system is to decide 
“on the spot” or schedule online among the various versions available, which version should a trans¬ 
action read from? Unfortunately this notion of online scheduling can sometimes lead to unnecessary 
aborts of transactions if not done carefully. To capture the notion of online scheduling which avoid 


unnecessary aborts in STMs, we have identified a new concept ols-permissiveness and is defined 
w.r.t a correctness-criterion, similar to permissiveness. We show that it is impossible for a STM sys¬ 
tem that is permissive w.r.t opacity to such avoid un-necessary aborts i.e. satisfy ols-permissiveness 
w.r.t opacity. We show this result is true for mvc-opacity as well. 

1 Introduction 

In recent years, Software Transactional Memory systems (STMs) ifTOl |23l have garnered significant 
interest as an elegant alternative for addressing concurrency issues in memory. STM systems take op¬ 
timistic approach. Multiple transactions are allowed to execute concurrently. On completion, each 
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transaction is validated and if any inconsistency is observed it is aborted. Otherwise it is allowed to 
commit. 

An important requirement of STM systems is to precisely identify the criterion as to when a trans¬ 
action should be aborted/committed. Commonly accepted correctness-criterion for STM systems is 
opacity proposed by Guerraoui, and Kapalka fTlI. Opacity requires all the transactions including aborted 
to appear to execute sequentially in an order that agrees with the order of non-overlapping transactions. 
Unlike the correctness criterion for traditional databases serializability ifT^ . opacity ensures that even 
aborted transactions read consistent values. 

Another important requirement of STM system is to ensure that transactions do not abort unneces¬ 
sarily. This referred to as the progress condition. It would be ideal to abort a transaction only when it 
does not violate correctness requirement (such as opacity). However it was observed in fTi that many 
STM systems developed so far spuriously abort transactions even when not required. A permissive STM 
l|6l does not abort a transaction unless committing of it violates the correctness-criterion. 

With the increase in concurrency, more transactions may conflict and abort, especially in presence 
many long-running transactions which can have a very bad impact on performance Q. Perelman et al 
ll^ observe that read-only transactions play a significant role in various types of applications. But long 
read-only transactions could be aborted multiple times in many of the current STM systems ifTTl ffl. In 
fact Perelman et al ll^ show that many STM systems waste 80% their time in aborts due to read-only 
transactions. 

It was observed that by storing multiple versions of each object, multi-version STMs can ensure that 
more read operations succeed, i.e., not return abort. History shown in Figure [T] illustrates this idea, 
qii : ri{x, 0)w2{x, 10)w2{y, 10)c2ri(y, 0)ci . In this history the read on y by Ti returns 0 instead of 
the previous closest write of 10 by T 2 . This is possible by having multiple versions for y. As a result, 
this history is opaque with the equivalent correct execution being T 1 T 2 . Had there not been multiple 
versions, r 2 {y) would have been forced to read the only available version which is 10. This value would 
make the read cause r 2 {y) to not be consistent (opaque) and hence abort. 
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Figure 1: Pictorial representation of a History 

Checking for membership of multi-version view-serializability (MVSR) 1251 chap. 3], the correctness 
criterion for databases, has been proved to be NP-Complete EOll . We believe that the membership of 
opacity, similar to MVSR, can not be efficiently verified. 

In databases a sub-class of MVSR, conflict-serializability (CSR) Il25l chap. 3] has been identified, 
whose membership can be efficiently verified. As a result, CSR is the commonly used correctness 
criterion in databases since it can be efficiently verified. In fact all known single-version schedulers 
known for databases are a subset of CSR. Similarly, using the notion of conflicts, a sub-class of opacity, 
conflict-opacity (co-opacity) can be designed whose membership can be verified in polynomial time. 
Further, using the verification mechanism, an efficient STM implementation can be designed that is 
permissive w.r.t co-opacity 113. Further, many STM implementations have been developed that using 
the idea of CSR|l3ll2l- 

By storing multiple versions for each transaction object, multi-version STMs provide more concur¬ 
rency than single-version STMs. But the main drawback of co-opacity is that it does not admit histories 
that are uses multiple versions. In other words, the set of histories exported by any STM implementation 
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that uses multiple versions is not a subset of co-opacity. Thus it can be seen that the co-opacity does not 
take advantage of the concurrency provided by using multiple versions. 

This has motivated us to develop a new conflict notions for multi-version STMs. In this paper, 
we present a new conflict notion mv-conflict. Using this conflict notion, we identify a new subclass 
of opacity, mvc-opacity whose membership can be verified in polynomial time. We further show that 
co-opacityis a proper subset of this class. Further, the conflict notion developed is applicable on non¬ 
sequential histories as well unlike traditional conflicts. 

In this paper, although we employed this conflict notion on opacity to develop the sub-class mvc-opacity, 
we believe that this conflict notion is generic enough to be applicable on other correctness-criterion such 
as local opacity IfTTl . virtual worlds consistency IT^ etc. 

An important question that arises while building a multi-version STM system using the proposed 
mv-conflict notion: among the various versions available, which version should a transaction read from? 
The question was first analyzed in the context of database systems SIlOl. A transactional system (either 
Database or STM) must decide “on the spot” or schedule online which version a transaction can read 
from based on the past history. 

Unfortunately this notion of online scheduling can sometimes lead to unnecessary aborts of trans¬ 
actions. For instance, suppose a transaction Tj requests a read on transaction object x. Let the STM 
system has option of returning a value for x from among two versions, say vi and V 2 - Suppose that the 
STM sytsem returns a version V 2 - It is possible that this read can cause another Tj to abort in later to 
maintain correctness. But this abort of Ti could have been avoided if the system returned instead. 
This concept is better illustrated in Section]^ where we show the difficulties with online scheduling. 

To capture the notion of online scheduling which avoid unnecessary aborts in STMs, we have iden¬ 
tified a new concept ols-permissiveness. It is defined w.r.t a correctness-criterion, similar to permissive¬ 
ness. We show that it is impossible for a STM system that is permissive w.r.t opacity to such avoid un¬ 
necessary aborts i.e. satisfy ols-permissiveness w.r.t opacity. We show this result is true for mvc-opacity 
as well. We believe that this impossibility result will generalize to other correctness-criterion such as 
LOlEl. 

Roadmap. We describe our system model in Section In Section we formally define the conflict 
notion and describe how to verify its membership in polynomial time using graph characterization. In 
Section we describe about the difficulty of online scheduling and associated impossibility results. 

In Section we discuss about extending the mv-conflict notion to local-opacity and then give a brief 
outline of how to develop a STM system using mvc-opacity. Finally we conclude in Section|^ 

2 System Model and Preliminaries 

The notions and definitions described in this section follow the definitions of ifTTl [I] . We assume a 
system of n processes (or threads), pi,... ,pn that access a collection of objects via atomic transactions. 
The STM systems is a software library that exports to the processes with the following transactional 
operations or methods', (i) tbegin operation, that starts a new transaction. It returns an unique transaction 
id; (ii) the write{x, v) operation that updates object x with value v, (iii) the read{x) operation that returns 
a value read in x; (iv) tryC{) that tries to commit the transaction and returns ok or abort', (iv) tryA{) that 
aborts the transaction and returns abort. The objects accessed by the read and write operations are called 
as transaction objects. For the sake of simplicity, we assume that the values written by all the transactions 
are unique. We also assume that the library ensures deferred update semantics, i.e. the write performed 
by a transaction on a transaction object x will be visible to other transactions only after the commit 
of Tfc. 

The transactional operations could be non-atomic. To model this, we assume that all these operations 
have an invocation and response events. The operations of a transaction consists of the following events: 
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tbegin consists of tbegin.inv{) which is followed hy a tbegin.rsp{i) where i is the id of the transac¬ 
tion. The read hy transaction Tk is denoted as readk{x).inv{) which is followed hy readk{x).rsp{v) 
where v is either the current value of x or A. Similarly, the write hy transaction Tk is denoted as 
writek{x,v).inv{) which is followed hy writek{x,v).rsp{r) where r denotes the result of the write 
operation. It can either he ok or A. The tryC hy transaction Tk is denoted as tryCk-inv{) which is 
followed hy tryCk-rsp{r) where r is either ok or A. Similarly, try A hy transaction Tk is denoted as 
tryAk-invO which is followed hy tryAk.rsp{A). When A is returned hy an operation, it implies that 
the transaction Tk is aborted. 

In the case where the operations are atomic, then we simplify the notation, tbegin is represented as 
tbegiuk, read as readk{x, v)/readk{x, A), read as writek{x, v)/writek{x, ^4), tryC as tryCk{ok)/tryCk{A), 
tryA as tryAk{A). 

When the write, read and tryC{) return A, we say that the operation forcefully aborted. Otherwise, 
we say that the operation has successfully executed. For simplicity we also refer to tryCk.rsp{ok) 
(tryCk{ok) in case of atomic operations) as Ck- Similarly, when a transactional operation returns A, i.e. 
readk{x).rsp{A),writek{x, v).rsp{A),tryCk.rsp{A),tryAk.rsp{A) {readk{x, A),writek{x, A), 
tryCk{A),tryAk{A) respectively), we denote the event as Ofc. Along the same lines, we refer to (non- 
atomic) read and write operations as rk{x, v),Wk{x, v) when the invocation and response events are not 
relevant to the context. Sometimes, we also drop the transaction object x and the value v read/written 
depending on the context. 

For a transaction Tk, we denote all the events (operations in case of sequential histories) of Tk as 
evts{Tk). All the transaction objects read by Tk are denoted as rset(Tk) and all the transaction objects 
written by it are denoted as wset{Tk). 

Histories. A history is a sequence of events, i.e., a sequence of invocations and responses of transac¬ 
tional operations. The collection of events is denoted as evts{H). We denote <h a total order on the 
transactional events in H. We identify a history H as tuple {evts{H), <h)- Figureshows history 
dn : wi{x,5).inv{) W 2 {x, 10).inv{) wi{x,5).rsp{ok) W 2 {x, 10).rsp{ok) r^{x).inv{) tryCi.rsp{ok) 
tryC 2 .rsp{ok) r3(x).rsp(5) . In Figure]^ for simplicity we have not shown inv and rsp events sepa¬ 
rately. 

We say a history is sequential if invocation of each transactional operation is immediately followed 
by a matching response. For simplicity, we treat each transactional operation as atomic in sequential 
histories. The order <h is a total order on the transactional operations in H for sequential histories. 
History ffj^shown in Figure[^is a sequential history. We also refer to histories which are not sequential 
as nonsequential. 
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Figure 2: Pictorial representation of a History H^ 

Let H\Tk denote the sub-history consisting of events of Tk in H. We only consider well-formed 
histories here, i.e., (1) each H\Tk consists of a read-only prefix (consisting of read operations only), 
followed by a write-only part (consisting of write operations only), possibly completed with a tryC or 
tryA operation. In the read-only prefix, each transaction consists of read on a transaction object x only 
once. This restriction brings no loss of generality ifTSl ; (2) a thread invoking transactional operations 
never invokes another operation before receiving a response from the previous one; it does not invoke 
any operation opk after receiving a Ck or Ok response. 
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We denote the set of transactions that appear in H is denoted by txns{H). A transaction G 
txns{H) is complete in H if H\Tk ends with a response event. In other words, all the operations in 
Tk end with a response event. We assume that all the operations in sequential histories are complete. 
A transaction G txns{H) is t-complete if H\Tk ends with or Ck ; otherwise, Tk is t-incomplete. 
The history H is t-complete if all transactions in txns{H) are t-complete. The set of committed (resp., 
aborted) transactions in H is denoted by committed{H) (resp., aborted{H)). The set of incomplete or 
live transactions in H is denoted by live(H) (live{H) = txns{H) — committed{H) — aborted{H)). In 
T 3 is live while Ti, T 2 are committed. 

We assume that every history has an initial committed transaction Tq that initializes all the trans¬ 
action objects with 0. We say that two histories, H and H' are equivalent, denoted as H Ki H' if 
evts{H) = evts{H') i.e. all the events in H and H' are the same. Note that H could be non-sequential 
whereas H' could be sequential. 

Transaction orders. For two transactions T^,, G txns{H), we say that Tk precedes Tm in the real¬ 
time order of H, denote Tk -<^ T^, if Tfc is t-complete in H and the last event of Tk precedes the first 
event of T^ in H. If neither Tk -<^ Tm nor Tm -<^ Tk, then Tk and Tm overlap in H. Consider two 
histories h, H' that are equivalent to each other, i.e. evts{H) = evts{H'). We say a history H respects 
the real-time order of another history H' if all the real-time orders of H' are also in H, i.e. 

A history H is t-sequential if there are no overlapping transactions in H, i.e., every two transactions 
are related by the real-time order. 

Correctness Criterion. We denote a collection of histories as correctness-criterion. Typically, all 
the histories of a correctness-criterion satisfy some property. Serializability ifT^ is the well-accepted 
correctness-criterion in databases. Several correctness-criteria have been proposed for STMs such as 
Opacity f7j. Virtual World Consistency ifT^ . Local Opacity lUTll . TMS |21 etc. 

Implementations. A STM implementation provides the processes with functions for implementing read, 
write, tryC (and possibly try A) functions. We denote the set of histories generated by a STM implemen¬ 
tation I as gen{I). We say that an implementation I is correct w.r.t to a correctness-criterion C if all the 
histories generated by / are in C i.e. gen{I) C C. 

Progress Conditions. Let C be a correctness-criterion with H in it. Let Ta be an aborted transaction in 
H. We say that a history H is permissive w.r.t C if committing Ta, by replacing the abort value returned 
by an operation in Ta with some non-abort value, would cause H to violate C. In other words, if Ta is 
committed then H will no longer be in C. We denote the set of histories permissive w.r.t C as perm{C). 
We say that STM implementation I is permissive [hj w.r.t some correctness-criterion C (such as opacity) 
if every history H generated by I is permissive w.r.t C, i.e., gen{I) C perm{C). 

3 New Conflict Notion for Multi-Version Systems 

In this section, we define a new conflict notion for multi-version STM systems. First, we describe about 
the Opacity fTj, a popular correctness-criterion. Then we describe the new conflict notion, multi-version 
conflict order. 

3.1 Opacity 

We define a few notations on histories for describing opacity. 

Valid, Legal and Multi-versioned histories. Let FT be a non-sequential history and rfc(x, v) be a success¬ 
ful read operation (i.e u / A) in H. Then rk{x, v), is said to be valid if there is a transaction Tj in H such 
that Tj is committed in H, Wj{x, v) is in evts{Tj) and the response of does not occur before invoca¬ 
tion of tryCj in H. Formally, {rk{x, v) is valid 3Tj : (rk(x).rsp(v) fin tryCj.inv{)) A {wj{x, v) G 
evts{Tj)) A {v / A)). We say that the commit operation tryCj.rsp{ok) (or Cj) is r^’s valWrite and 
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formally denote it as H.valWrite{rk). The history H is valid if all its successful read operations are 
valid. The notion of validity formalizes deferred update semantics described in Section 

In tryCi.rsp{ok) = ci = I^^valWrite{r^{x,fi)), rk{x).rsp{5) tryCi.inv{) and 

{wi{x, 5) G evts{Ti)). Hence, r 3 (x, 5) is valid and as a result, iij^is valid as well. 

For a sequential history H, the definition of validity of rk{x, v) boils down as follows: a successful 
read rfc(x, v), is said to be valid if there is a transaction Tj in H that commits before and writes v to 
X. Formally, {rk{x,v) is valid 3Tj : (cj <h rk{x,v)) A {wj{x,v) G evts{Tj)) A (u / A)). 

Consider a sequential history H. We define rk{x, v)’s lastWrite as fhe lafesf commif evenf such 
fhaf Ck precedes rk{x,v) in H and x G Wset{Tk) (Tk can also be Tq). Formally, we denote if as 
H.lastWrite{rk)■ A successful read operation rk{x,v) (i.e v 7 ^ A), is said fo be legal if fransacfion 
Tk (which confains r^’s lasfWrile) also writes v onto x. Formally, {rk{x,v) is legal (u / A) A 
{H.lastWrite{rk{x,v)) = Ck) A {wk{x,v) G evts{Tk))). The sequential history H is legal if all ifs 
successful read operafions are legal. Thus from fhe definifion, we gel lhal if H is legal fhen if is also 
valid. 

If can be seen fhaf in cq = I^valWrite{ri{x,0)) = l^lastWrite{ri{x,0)). Hence, 
ri(x, 0) is legal. Bui cq = l^valWrite{ri{y, 0)) ^ ci = I^lastWrite{ri{y, 0)). Thus, ri(y, 0) is 

valid buf nof legal. 

We denole a sequential hislory H as non-single-versioned if if is valid buf not legal. If a hislory H 
is non-single-versioned, fhen Ihere is al leasl one read, say rk{x) in H lhal is valid bul nol legal. The 
history H[^is non-single-versioned. This definition can nol be generalized to non-sequenlial histories as 
legality is nol defined for non-sequenlial histories. 

Opacity. To define Ihe correclness-crilerion opacity, we firsl define completion of a history lhal is in¬ 
complete. For a history H, we conslrucl Ihe completion of H, opq-completion denoted H°, as follows 
(similar to |T1): 

1. for every complete Iransaclion Tk in H lhal is nol l-complele, inserl Ihe evenl sequence: 
tryAk.inv{) tryAk.rsp{A) after Ihe Iasi evenl of Iransaclion T^; 

2. for every incomplete operation opk of Tk in H, if opk = readk V writsk V tryAk, then insert the 
response event A somewhere after the invocation of opk ; 

3. for every incomplete tryCk operation where Tk is in H, insert response event ok or A somewhere 
after the invocation of tryCk- 

In case of a sequential history H, the completion H° is constructed by inserting an tryAk {A) (or 
Ok) after the last operation of transaction Tk, for every transaction Tk in H that is t-incomplete. 

A history H is said to be opaque (T) [H if Ff is valid and there exists a t-sequential legal history S 
such that (1) S is equivalent to H° and (2) S respects i.e 

By requiring S being equivalent to H°, opacity treats all the incomplete transactions as aborted. 
The validity requirement on H ensures that write operations of aborted transactions are ignored. This 
definition of opacity is closer in spirit to du-opacity |Tl. It can be seen that both the histories 
and Hj^are opaque. The opaque equivalent t-sequential history for Fi[^ being riT 2 and the equivalent 
t-sequential histories of Fi[^are T 1 T 3 T 2 , T 2 TiT^ . 

3.2 Motivation for a New Conflict Notion 

It is not clear if checking whether a history is opaque or can be performed in polynomial time. Checking 
for membership of multi-version view-serializability (MVSR) ll25l chap. 3], the correctness criterion for 
databases, has been proved to be NP-Complete |[20l . We believe that the membership of opacity, similar 
to MVSR, can not be efficiently verified. 
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In databases a sub-class of MVSR, conflict-serializability (CSR) |[25l chap. 3] has been identified, 
whose membership can be efficiently verified. As a result, CSR is the commonly used correctness- 
criterion in databases since it can be efficiently verified. In fact all known single-version schedulers 
known for databases are a subset of CSR. Similarly, using the notion of conflicts, a sub-class of opacity, 
conflict-opacity (co-opacity) can be designed whose membership can be verified in polynomial time. 
Further, using the verification mechanism, an efficient STM implementation can be designed that is 
permissive w.r.t co-opacity ifT^fTTll . 

As already discussed in Section [TJ by storing multiple versions for each transaction object, multi¬ 
version STMs provide more concurrency than single-version STMs. But the main drawback of co-opacity 
is that it does not admit histories that are non-single-versioned. Thus co-opacity does not take advantage 
of the concurrency provided by using multiple versions. Another big drawback being that co-opacity 
does not admit histories that are non-sequential. In other words, the set of histories exported by many 
STM implementation are not a subset of co-opacity. Hence, proving correctness of these STM systems 
is difficult. In the rest of this sub-section, we formally define co-opacity and show the drawbacks. Some 
of the definitions and proofs in this section are coming directly from ifT^fTTll . 

We define co-opacity using conflict order |[25l Chap. 3]. Consider a sequential history H. For two 
transactions and Tm in txns{H), we say that precedes Tm in conflict order, denoted -<^ Tm, 
(a) (c-c order): Ck <h Cm and wset{Tk) Cl wset{Tm) / 0; (b) (c-r order): Ck <h 'r'm{x,v), x G 
wset{Tk) and u / A; (c) (r-w order) rk{x, v) <h Cm, x G wset{Tm) and v ^ A. 

Thus, it can be seen that the conflict order is defined only on operations that have successfully 
executed. Further, it can also be seen that this order is defined only for hisfories thaf are sequential. 

Using conflict order, co-opacity is defined as follows: A sequential history H is said to be conflict 
opaque or co-opaque if H is valid and there exists a t-sequential legal history S such that (1) S is 
equivalent to H° and (2) S respects -<^ and -<^^■ 

From the definitions of conflict order and co-opacity it is clear that these notions are only specific fo 
sequential histories. Thus, history Ffj^is not co-opaque. It must be noted that H[^can be generated by 
a STM system that maintains only a single version of each transaction object. The asynchronous nature 
of thread execution can result in H[^by the STM system. 

Having seen a drawback, we will next show that if any sequential history is non-single-versioned, 
then it can not be in co-opacity. 

Lemma 1 Consider two sequentiai histories H\ and H2 such that HI is equivaient to H2. Suppose 
H\ respects conflict order of H2, i.e., Then, 

Proof. Here, we have that A C . In order to prove A = A , we have to show that A C A . 
We prove this using contradiction. Consider two events p, q belonging to transaction Tl, T2 respectively 
in H2 such that (p, q) GA^^ but (p, q) Since the events of H2 and if 1 are same, these events 

are also in fil. This implies that the events p, q are also related by CO in iil. Thus, we have that 
either (p, q) GA^^ or (q,p) GA^®. But from our assumption, we get that the former is not possible. 
Hence, we get that (q,p) GA^^A> {q,p) GA^f. But we already have that (p, g) GA^^. This is a 
contradiction. □ 


Lemma 2 Let H 1 and H2 be two sequentiai histories which are equivaient to each other and their 
conflict order are the same, i.e. A^^=A^^. Then H\ is iegai iff H2 is iegai. 

Proof. It is enough to prove the ‘if’ case, and the ‘only if’ case will follow from symmetry of the 
argument. Suppose that iil is legal. By contradiction, assume that H2 is not legal, i.e., there is a read 
operation rj{yx,v) (of transaction Tj) in H2 with its lastWrite as Ck (of transaction Tk) and Tk writes 
u V to x, i.e. Wk{x, u) G evts{Tk). Let rj{x, vfs lastWrite in iil be q of Ti. Since iil is legal, Tj 
writes v to x, i.e. Wi{x, v) G evts{Ti). 
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Since evts{H\) = evts{H2), we get that Ci is also in H2, and is also in HI. As 
wegetcj <h2 rj{x,v) and Cfe <hi rj{x,v). 

Since Cj is the lastWrite of rj{x,v) in iff we derive that Ck <hi Ci and, thus, Ck <h 2 Ci <H2 
rj{x, v). But this contradicts the assumption that Ck is the lastWrite of rj{x, v) in H2. Hence, H2 is 
legal. □ 


Lemma 3 If a sequential history H is non-single-versioned then H is not in co-opacity. Formally, 
{{His sequential)/\ {His non-single-versioned) {H co-opacity)). 

Proof. We prove this using contradiction. Assume that H is non-single-versioned, i.e. H is valid but 
not legal. But suppose that H is in co-opacity. Since H is sequential, conflict order can be applied on 
it. From the definition of co-opacity, we get that there exists a t-sequential and legal history S such 
that From Lemma we get that Combining this with Lemma and the 

assumption that H is not legal, we get that S is not legal. But this contradicts out assumption that S 
legal. Hence, H is not in co-opacity. □ 


3.3 Multi-Version Conflict Defi ni tion 

Having seen the shortcomings of co-opacity, we will see how to overcome them. The main reason for the 
shortcoming is because conflict notion has been defined only among the events of sequential histories. 
We address this issue here by defining a new conflict notion for non-sequential histories. 

To define this notion on any history, we have developed a another definition of completion of any 
history H, mvc-completion denoted as H^. It is same as H° except for step which is modified as 
follows: for every incomplete tryCk operation where Tk is in H, insert response event A somewhere 
after the invocation of tryCk- Thus in iT™, all incomplete tryC operations are treated as aborted. 

Definition 1 For a history H, we define multi-version conflict order(mvc order), denoted as 
between operations of H"^ as follows: (a) commit-commit (c-c) order: Ci Cj if tryCi.rsp{ok) <h 
tryCj .rsp{ok) for two committed transaction Ti, Tj and both of them write to x; (b) commit-read (c- 
r) order: Let ri{x,v) be a read operation in H with its valWrite as Ck (belonging to the committed 
transaction Tk). Then for any committed transaction Tj that writes to x, either the response of the Tj ’s 
commit occurs before Tk or Tk is same as Tj, formally {tryCj.rsp{ok) <h tryCk-rsp{ok)) V {Tj = 
Tk), we define Cj r^. (c) read-commit (r-c) order: Let rfix^v) be a read operation in H with 

its valWrite as Ck. Then for any committed transaction Tj that writes to x, if the Tj ’s commit response 
event occurs after Tk’s commit response event, i.e. {tryCk■rsp{ok) <h tryCj.rsp{ok)), we define 

.mvc . 

U -Sh h- 

Observe that the mvc order is defined on the operations (and not events) of H^ and not H. The set 
of conflicts in are: [c-r : (cq, ra), (ci, rs)], [r-c : (rs, C 2 )], [c-c : (cq, ci), (cq, C 2 ), (ci, C 2 )]. Here, it 
can be observed that tryC 2 -rsp{ok) occurs before rs{x).rsp{5). Yet, ra occurs before C 2 in the mvc 
order. 

It is not difficult to extend the mvc order to sequential histories: replace the response of a tryC event 
with the corresponding tryC operation and the response of a read event with the corresponding read oper¬ 
ation. The set of conflicts in iij^are: [c-r : (cq, ri(x, 0)), (co,ri(y))], [r-c : (ri(x),C 2 ), (ri(y),C 2 )], [c-c : 
(C0,C2)]. 

We say that a history H' satisfies the mvc order of a history H, denoted as H' if: 

(1) Ff' is equivalent to FF™; (2) Consider two operations opi, opj in H. Let e*, Cj be the corresponding 
response events of these operations. Then, opi opj implies Cj <h' ej. If FF, FF' are sequential, 

then op and e would be the same. 





Note that for any sequential history H that is non-single-versioned, H does not satisfy its own mvc 
order For instance the non-single-versioned order in history ffj^consists of the pair: (ri(y, 0), C 2 ). 

But C 2 occurs before ri{y, 0) in HI. We formally prove this property using the following lemmas. 

Lemma 4 Consider a valid history H. Let H' be a sequential history (which could be same as H). If 
H' satisfies then H' is legal. Formally, {{H is valid) A {H' is sequential) A {H' 

[H' is legal)). 

Proof. Assume that H' is not legal. Hence there exists a read operation, say rfix, v), in evts{H') that is 
not legal. This implies that lastWrite of ri is not the same as its valWrite. Let q = H'.lastWrite{ri) 7 ^ 

H'.valWrite{ri) = Cy. Let wi{x,u) G evts{Ti) and Wy{x,v) G evts{Ty) where {Ti,Ty,Ti} G 
txns{H'). As H is valid, we have that tryCy.rsp{ok) <h ri{x).rsp{v). Since H' we have 

that evts{H) = evts{H'). Thus {T;, T^, Tj} are also in txns{H). 

There are two cases w.r.t ordering of events in H: 

• tryCi.rsp{ok) fryC^,.rsp(oA:): From the definition of mvc order, we get that tryC';.rsp(o/c) 
tryCv.rsp{ok). Since H' satisfies and is sequenfial, we gef fhaf q Kh’ Cy <h' A- 

• tryCy.rsp{ok) <h tryCi.rsp{ok): Again, from fhe definition of mvc order, we gef fhaf a (x).rsp(u) 
^mvc tryCi.rsp{ok). Since H' satisfies and is sequenfial, we gel lhal Cy <h' ri <h' Q. 

In bofh cases, if can be seen lhal q is nof Ihe previous closesl commil operafion lo in H'. Hence, 
we have a confradiclion which implies H' is legal. □ 

Using fhis lemma, we gel Ihe following corollary. 

Corollary 5 Consider a valid history H. Let H' be a non-single-versioned history equivalent to H 
(which could be same as H). Then, H' does not satisfy Formally, {{H' is non-single-versioned) A 

{H is valid) F{H' ^ H) {H' 

Proof. We are given lhal H is valid, H and H' are equivalenl lo each olher. Since H' is non-single- 
versioned, we gel lhal H' is sequential bul nol legal. Combining all Ihese wilh Ihe conlraposilive of 
Lemma|^ we gel lhal H' □ 

Now, we show lhal if a history is legal, Ihen if satisfies if own mv-conflicl order. 

Lemma 6 Consider a legal history H. Then, H satisfies its own mv-conflict order Formally, 

{{His legal) {HF<ff’<^)). 

Proof. We are given lhal H is legal. From Ihe definition of legality, we gel lhal S is sequential. We 
will prove Ihis lemma using conlradiclion. Suppose, H does nol satisfy ils own mv-conflicl order i.e. 

{H F^fij"^). Consider Iwo operations, say pi (belonging to Iransaclion Tj) and qj (belonging to Irans- 
aclion Tj) in evts{H). From our assumption of conlradiclion, we gel lhal {pi qj) bul {pi fu Qj)- 
This implies lhal {qj <h Pi) since all Ihe operations are lolally ordered in H (which is sequential). Lei 
us consider Ihe various cases of mv-conflicl belween pi and qj: 

• Pi = Ci,qj = Cj (c-c order): From mv-conflicl definition, we gel lhal q cj implies lhal 

A <H Cj. 

• Pi = Ci, qj = rj (c-r order): Lei Ihe valWrile of ty in H be Cy belonging to Iransaclion Ty. From 
mv-conflicl definition, we gel lhal eilher Cj <h Cy <h ty or q = Cy <h ty- In eilher case, we 
have lhal Ci <h ty - 
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• Pi = fi, Qj = Cj (r-c order): Similar to the above case, Let the valWrite of in H be belonging 
to transaction Ty. From mv-conflict definition, we have two option: (i) Cy <h Ci <H fj or (ii) 
Cv <H fj <H Ci- Since H is legal, option (i) is not possible (unless Cy = ci). This leaves us with 
option (ii), Vj <h d- 

Thus in all the three cases, we get that {pi <h qj) which implies that H satisfies □ 

We now prove an interesting property about satisfaction relation. 


Lemma 7 Consider a valid history H and a sequential history S. If, S satisfies H ’s mv-conflict order 
then S also respects H’s mv-conflict order. Formally, {{H is valid) A{S is sequential) A {S 


Proof. We are given that FI is valid, S is sequential and satisfies mv-conflict order Thus, 

from Lemma 1^ we get that S is legal. From Lemma we get that S satisfies its own mv-conflict order 




H ,i.e.5h^™ 


Now, we prove this lemma using contradiction. Suppose, S satisfies but S does not respect 
mv-conflict order of H, i.e. . This implies that there exists two operations, pi, qj in H and 

S such that pi precedes qj in H’s mvc order but not in S’s mvc order. We have that. 


{p, q,) A {p, q,) 




> {pi Qj) ^ (Pi Qj) 


. .. ..- - > {Pi <S Qj) F {pi fs Qj)- 

satisfy def n 

This implies a contradiction. Hence, we have that S respects mv-conflict order of H. 


□ 


3.4 Multi-Version Conflict Opacity 

We now illustrate the usefulness of the conflict notion by defining another subset of opacity mvc-opacity 
which is a superset of co-opacity. We formally define it as follows (along the same lines as co-opacity): 

Definition 2 A history H is said to be multi-version conflict opaque or mvc-opaque if H is valid and 
there exists a t-sequential history S such that (1) S is equivalent to H^, i.e. S ~ H^; (2) S respects 
, i.e. and S satisfies i.e. S . 

It can be seen that both the histories fi[^and ffj^are mvc-opaque. The mvc equivalent t-sequential 
history for H[^being T 1 T 2 and the equivalent t-sequential history for fi[^being T 1 T 3 T 2 . 

Consider a history H that is mvc-opaque and let S be the mvc equivalent t-sequential history. Then 
from Lemma|^ we get that S satisfies H’s mv-conflict order, i.e. Please note that we don’t 

restrict S to be legal in the definition. But it turns out that if H is mvc-opaque then S is automatically 
legal as shown in Lemma Now, we have the following theorem. 

Theorem S If a history H is mvc-opaque, then it is also opaque. Formally, {{H G mvc-opacity) 

{H G opacity)). 

Proof. Since H is mvc-opaque, it follows that H is valid and there exists a t-sequential history S such 
that (1) S is equivalent to Ff™ and (2) S respects and S satisfies Since, S is equivalent to 

FF”*, it can be seen that S is equivalent to H° as well. This, in order to prove that FF is opaque, it is 
sufficient to show that S is legal. As S satisfies from Lemmaj^we get that S is legal. Hence, FF 
is opaque as well. □ 

Thus, this lemma shows that mvc-opacity is a subset of opacity. Actually, mvc-opacity is a strict sub¬ 
set of opacity. Consider the history Fi[^= ri{x,0)r2{z,0)r3{z,0)wi{x,5)cir2{x,5)w2{x,W)w2{y,15) 
C 2 f' 3 {x, 5 )w 3 {y, 25)c 3. . Figure shows the representation of this history. The set of mv-conflicts in 
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are (ignoring the conflicts with Co): [c-r : (ci, r2(x, 5)), (ci, r3(x, 5))], [r-c : (r3(x, 5), C2)], [c-c ; 
(ci, C2), (c2, C3)]. It can be verified that is opaque with the equivalent t-sequential history be¬ 
ing T 1 T 3 T 2 . But there is no mvc equivalent t-sequential history. This is because of the conflicts: 
(r3(x, 5), C2), (c2, C3). Hence, ii|^is not mvc-opaque. 


ri{x, 0) 

wi{x, 5) 

C; 





T 2 


r 2 {x, 0 ) 


r2{x, 5) W2{x, 10) 


C 2 

W2iy, 15) 


T 3 


r3(2,0) 
-•- 


C3 

W3{y,25) iiJ3(y,25) 

- • - • - 


Figure 3: Pictorial representation of 

Next, we will relate the classes co-opacity and mvc-opacity. In the following theorem, we show that 
co-opacity is a subset of mvc-opacity. 

Theorem 9 If a history H is co-opaque, then it is also mvc-opaque. Formally, {{H G co-opacity) 

{H G mvc-opacity)). 

Proof. Since FI is co-opaque, we get that there exists an equivalent legal t-sequential history S that 
respects the real-time and conflict orders of H. Thus if we show that S satisfies mvc order of H then H 
is mvc-opaque. From the definition of co-opacity, we have that H is sequential. 

Since S is legal, it turns out that the conflicts and mv-conflicts are the same. To show this, let us 
analyse each conflict order: 

• c-c order: If two operations are in c-c conflict, then by definition they are also ordered by the c-c 
mvc order. 

• c-r order: Consider the two operations, say and ri that are in conflict (due to a transaction object 
x). Hence, we have that Ck <h Ti. Let c„ = H.valWrite{ri). Since, S is legal, either Ck = Cy or 
Cfc <H Cj. In either case, we get that Ck r*. 

• r-c order: Consider the two operations, say Ck and that are in conflict (due to a transaction object 
x). Hence, we have that r* <h Ck. Let Cy = H.valWrite{ri). Since, S is legal, c„ <h rt <h Ck. 
Thus in this case also we get that r* Ck. 

Thus in all the three cases, conflicts among the operations in S also result in mv-conflicts among 
these operations. Hence, S satisfies the mvc order of H. □ 

This theorem shows that co-opacity is a subset of mvc-opacity. The history is mvc-opaque 
but not in co-opaque. Hence, co-opacity is a strict subset of mvc-opacity. Figure shows the relation 
between the various classes. 

3.5 Graph Characterization of MVC-Opacity 

In this section, we will describe graph characterization of mvc-opacity. This characterization will enable 
us to verify its membership in polynomial time. 

Given a history H, we construct a multi-version conflict graph, MVCG{H) = {V, E) as follows: 
(1) V = txns{H), the set of transactions in H\ (2) an edge {Ti,Tj) is added to E whenever 
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Figure 4: Relation between the various elasses 


2.1 real-time edges: If Tj preeedes Tj in iF; 

2.2 mve order edges: If Tj eontains an operation pi and Tj eontains pj sueh that pi pj. 

The multi-version eonfiiet graph gives us a polynomial time graph eharaeterization for mve-opaeity. We 
show it using the following lemma and theorem. 

Lemma 10 Consider a legal and t-sequential history S. Then, MVCG{S) is acyclic. Formally, 

{{S is legal) A {S is t-sequential) => {MVCG{S) is acyclic)). 

Proof. Sinee S is t-sequential, we ean order all the transaetions by their real-time order. We assume 
w.l.o.g that all the transaetions of S are ordered as Ti <5 T 2 <s ■■■■ <s Tn. Thus, with our assumption 
we get that Ti <s Tj implies that i < j. 

Now we will show that for any edge (Tj, Tj) in MVGG{S), we get that i < j. The edge (Tj, Tj) 
ean be one of the following: 

• real-time: It follows from this ease that Tj started only after the commit of Ti. Hence, we get that 
Ti <s Tj and this implies i < j. 

• c-c conflict: Here, we have that Cj <5 Cj. Since S is t-sequential, we get that all the events of Tj 
occur before all the events of Tj. Hence Ti <s Tj and thus i < j. 

• c-r conflict: Here, Cj <s Vj for a read rj{x, v). Since S is t-sequential, similar to the above case 
we get that Ti <s Tj and hence i < j. 

• r-c conflict: Here, rj <5 Cj for a read rj(x, v). Let valWrite of rj be ci. From the definition of 
mv-conflict, we have two cases. Either (i) q <5 Cj <s Vi or (ii) q <5 rj <s Cj. Since S is legal, 
we get that case (i) is not possible. Otherwise, Cj would have been the valWrite of rj. This leaves 
only case (ii) which implies that rj <5 Cj. Since S is t-sequential, similar to the above two cases 
we get that Ti <s Tj and hence i < j. 

Thus in all the cases, we get that an edge (Tj, Tj) in the MVGG{S) implies that i < j. Hence, a 
cycle is not possible in such a graph. □ 


Theorem 11 A valid history H is mvc-opaque iff MVGG{H) is acyclic. 
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Proof. We prove both the directions. 

if MVCG{H) is acyclic then H is mvc-opaque: Since MVCG{H) is acyclic, we can perform a 
topological sort on MVGG{H). Using the order obtained from the topological sort, we order all the 
transactions of to construct a t-sequential history S. Thus from the construction of S, we get that S 
is equivalent to 

It can be seen that S respects If Ti occurs before Tj in H, then there is an edge between Tj 

between Tj in MVGG{H). This edge ensures that Ti occurs before Tj in S as well. 

Consider two operations of H, pi (belonging to Ti) and qj (belonging to Tj). If pi qj then 

there is an edge between T and Tj in MVGG{H). This edge ensures that T <s Tj. Thus, we get that 
Pi <s Qj- This shows that S satisfies 

if H is mvc-opaque then MVGG{H) is acyclic: Since H is mvc-opaque, we get that there exists a 
t-sequential, legal history S that is equivalent to H. We also have that S respects the real-time order of 
H and satisfies mvc order of H. Combining this with Lemma we get that S respects the mv-conflict 
order of H. Formally, 

Thus, from the graph construction of MVGG{H), MVGG{S), we get that MVGG{H) C MVGG{S). 
Since S is legal and t-sequential, from Lemma 10 we get that MVGG{S) is acyclic. This implies that 
MVGG{H) is also acyclic since it is a subgraph of MVGG{S). □ 


Figure]^ shows the multi-version conflict graphs for the histories i^j^and In these graphs and 
other conflict graphs shown in this paper, we have ignored Tq for simplicity. 



Figure 5: multi-version conflict graphs of Ffj^and 


4 Online Scheduling with Multiple Versions 

An important question that arises while building a multi-version STM system is among the various 
versions available, which version should a transaction read from? The question was first analyzed in the 
context of database systems |l9j|20l. A transactional system (either Database or STM) must decide “on 
the spot” or schedule online which version a transaction can read from based on the past history. 

We say a STM implementation I schedules online (i.e. decides on the spot) if every invocation to an 
operation that it exports (read, write, tryC, try A) returns in finite time. We denote I as online schedulable 
(OLS) (term inspired from databases). Note that I can make a decision on scheduling based only on the 
past history of operations seen so far as it does not have any idea of the future. In other words, all the 
methods of I are wait-free. 

But unfortunately this notion of online scheduling can sometimes lead to unnecessary aborts of 
transactions. We illustrate this idea with an example while considering mvc-opacity as the correctness- 
criterion. Consider the sequential history wi{x, l)wi{y,vi)w2{x,2)rk{z,bi)ciW2{z,V2)c2r^{x,l\) 

In this history, r^{x) has the option of reading 1 from Ti or 2 from T 2 (denoted as r^{x, ^ 2 ))- T 3 can 
not read x from Tq as it would violate the real-time order requirement between Tq , Ti imposed by 
mvc-opacity(as well as opacity). Suppose T 3 reads 2 for x written by T 2 . Now consider a sequence of 
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events that follow the read operation. Let ii[^= wi{x, l)wi[y, vi)w 2 {x, 2)rk{z, 0 )ciW 2 {z, V 2 )rj{b, 0) 
C 2 r 3 {x, 2 )w 3 {b,V 3 )wk{b,Vk)wj{d,Vj). a possible extension of It can be seen that fi[^is 

mvc-opaque (with T 3 reading 2). But iij^is not as there is a cycle between the transactions T 2 , T 3 , in 
the multi-version conflict graph. 

Suppose T 3 had read 1 instead of 2 for x. Now consider the modified history consisting of same ex¬ 
tension of /i|^(assuming that the read of T 3 did not affect the future events), wi{x, l)wi{y, vi)w 2 {x, 2)rk{z, 0 )ciri 

It can be seen that /i[^is mvc-opaque. /fj^will be mvc-opaque if Tk is aborted. This shows that the 
versions read by a transaction can cause other transactions to abort in future. Figure illustrates this 
concept. 


T2 [- 


• W 

W2{x, 2 ) 

-•- 


102(2,1)2) I 

-•-1 C2 



D3) 




Tk 


rk{z,0) 
-•— 


Wk{b, Vk) 


Ck 




Figure 6 : Illustration of difficulties with online scheduling 

To capture the notion of online scheduling which avoid unnecessary aborts in STMs, we have identi¬ 
fied a new concept ols-permissiveness and is defined w.r.t a correctness-criterion, similar to permissive¬ 
ness. 

Let C be a correctness-criterion with a history H being permissive w.r.t C, i.e. H G perm{C). 
Then let Ta be an aborted transaction in H. Let ri{x, v) be any successful read operation(i.e. v ^ A)m 
H that completed before the abort response of Ta, i.e. {ri{x).rsp{v) <h ra(z).rsp(A )/ 
tryCa-rsp{A)/tryAa.rsp{A)) (for some r^). Suppose rj(x) read a different value u {A ^ u ^ v) 
from among the various versions available (that were created before by update transactions). Then, 
committing Ta, by replacing the abort value returned by an operation in Ta with some non-abort value, 
would cause H to violate C. In other words, if Ta were to be committed with rj(x) reading u, H will 
no longer be in C. We say that H is ols-permissive w.r.t C. 

In the above example, Fij^is not ols-permissive w.r.t mvc-opacity. We denote the set of histories that 
are ols-permissive w.r.t C as ols-perm{C). Along the same lines, we say that STM implementation I is 
ols-permissive w.r.t some correctness-criterion C (such as opacity) if every history H generated by I is 
ols-permissive w.r.t C, i.e., gen{I) C ols-perm{C). 

It turns out that multiple versions make online scheduling very difficult. In fact we show in the 
following sub-section that it is impossible to achieve ols-permissiveness. 
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4.1 On Impossibility of ols-permissiveness with multiple versions 

As mentioned above, multiple versions make online scheduling very difficult. In this sub-section, we 
hrst show that it is impossible for an OLS implementation I that to be ols-permissive w.r.t mvc-opacity. 
Then, we show that it is impossible for I to be ols-permissive w.r.t opacity as well. 

To show our result, we consider a centralized adversary A that has complete knowledge of the 
working of the implementation I. We assume that the adversary invokes the next method on the imple¬ 
mentation I based on the previous responses. It waits for the response of the previous event before it can 
hre the next invocation event. Hence, the histories considered in following sub-section are sequential. 
It must be noted that making this assumption does not restrict the generality of the results as sequential 
histories are a special case of histories. 

Theorem 12 No OLS STM implementation can be ols-permissive w.r.t mvc-opacity. 


Proof. Let us suppose that an OLS STM implementation I is ols-permissive w.r.t mvc-opacity. From 
the dehnition of ols-permissiveness, we get that I is also permissive w.r.t mvc-opacity. 

Some of the arguments used in this proof are similar to the description in the start of this section. 
Consider the sequential history I^= wi{x, l)wi{y, vi)w 2 {x, 2)rk{z, 0)ciW2{z, V 2 )rj{b, 0)c2rs{x, 

(this history is similar to TfQ. Assume that the adversary A invokes same operations on I as this history. 
Since I is permissive w.r.t mvc-opacity, it will not unnecessarily return abort to any of these operations. 

For the read rf^{z), I will return 0 since so far no write to z has taken place. The same argument holds 
for rj{b, 0). Thus the output by I is same as ii[^ until r^{x). 

For r^{x), I has the option of returning either 1 or 2. It can not return 0 (written by Tq) as it violate 
real-time ordering required by mvc-opacity. Suppose I returned 2 for the read r 3 (x). Now consider an 
extension of wi{x, vi)w 2 ix, 2)rk{z, Qi)ciW 2 {z, V 2 )rj{b, 0 )c 2 r 3 (x, 2)wi{b, V 3 )wk{b, Vk) 

Wj{d,Vj). It can be seen that is not mvc-opaque as there is a cycle between the transactions 
T 2 ,r 3 ,Tfc in the multi-version conflict graph. Suppose A invokes the operations of on I after 
the invocation of r 3 (x). Since not mvc-opaque, A invokes the next operation only after receiving 
the previous response and I is permissive w.r.t mvc-opaque, I would be forced to abort T^. 

Now, consider the case that I had returned 1 for r 3 (x) instead of 2. The resulting history, = 
wi{x, l)wi{y, vi)w 2 ix, 2)rk{z, 0 ) 01 ^ 2 ( 2 ;, V 2 )rj{b, 0 )c 2 r 3 (x, l)w 3 {b, V 3 )wk{b, Vk)wj{d, Vj)cjCk. It can 


be seen that mvc-opaque with an equivalent t-sequential history being TiTjT 3 TkT 2 . Thus, in this 
case I would not have to abort any transaction. H[^is in ols-perm{mvc-opacity). Figure [^illustrates 
this scenario. 

Next consider another extension of the history HIO = wi{x, l)wi{y, vi)w 2 {x, 2)rk{z, 0)ci 
W 2 {z, V 2 )rj{b, 0 ) 02 X 3 (x, l)w 3 {b, V 3 )wk{d, Vk)wj{z, Vj)cjCk. It can be seen that, if 10 is not mvc-opaque 


as there is a cycle between the transactions T 2 , Tj , T 3 in the multi-version conflict graph. Suppose A 
invokes the operations of HIO on I. Let I returns 1 for r 3 (x) (not knowing what operations could be 
invoked in future). Then in this case, I would be forced to abort Tj since MTOjis not mvc-opaque. 


A invokes the next operation only after receiving the previous response and I is permissive w.r.t mvc- 
opaque. 

On the other hand, suppose I returned 2 for the above sequence of operation invocation by A. The 
resulting history is flni = Wi{x, l)wi{y, Vi)w2{x, 2)rk{z, 0 )ci'«; 2 ( 2 ;, V2)rj{b, 0 )c 2 r 3 (x, 2)w3{b, V3) 
Wk{d, Vk)wj {z, Vj). It can be seen that this history is mvc-opaque with an equivalent t-sequential history 
being TiTkT 2 TjT 3 . Hence, in this case I would output this history without aborting any transaction. 
fj[IT]is in ols-perm{mvc-opacity). Figure [^ illustrates this scenario. 

These examples illustrate that given the sequence of operations in H^ returning either 1 or 2 for 
r 3 (x) by I can possibly cause some transaction in future to abort depending on the sequence of in¬ 
vocations. Whereas reading the other value would have avoided the abort. This is because when I 
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Figure 7: F/[^containing 03 ( 2 :, 1) is mvc-opaque 



Figure 8 : ij[IT] containing r 3 (x, 2 ) is mvc-opaque 
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received the event rs{x), it has no idea about the future events and is OLS. Hence, I can not be in 
ol s-perm{mvc-opacity). 

The difficulty of online scheduling is not restricted only to mvc-opacity. We now show that the 
impossibility extends to opacity as well. In showing this, we use arguments very similar what we have 
used to the above proof. 

Theorem 13 No OLS STM implementation can be ols-permissive w.r.t opacity. 

5 Discussion 

5.1 Multi-Version Conflicts on other Correctness Criteria 

So far in this paper, we have demonstrated the effectiveness of mvc orders using opacity. This conflict 
notion can be applied to other correctness-criterion such as local-opacity (LO) ifTTIl and virtual world 
consistency (VWC) lIT^ . Both these correctness-criteria were defined for sequential histories. 

A history H is locally-opaque if the following conditions hold: (1) Let the sub-history Hcom consist 
of events from all the committed transactions in H. Then Hcom should be opaque; (2) Let Ta be an 
aborted transaction in H. Suppose Ha be a sub-history consisting of all the transactions that committed 
before the abort of Ta in H. Then, for each aborted transaction Ta, Ha is opaque. 

We say a history H is multi-version conflict local-opaque (MVLO) if for each history H, (1) Hcom 
is mvc-opaque; (2) for each aborted transactions Ta, Ha is mvc-opaque. 

Further, it can be seen that the impossibility results of Section]^ can be extended to MVLO and LO 
as well. 

We believe that along the same lines, the multi-version conflict definition can be extended to VWC. 

5.2 Outline of a STM System using Multiversion Conflicts 

Having developed a conflict definition that accommodates multiple versions, we describe the outline of 
a STM system.The main idea behind the algorithm is based on the notion serialization graph testing 
Il22l [TTl that was developed for databases Il25ll . According to this idea, the STM system maintains a 
graph based on the operations that have been executed so far. A new operation is allowed to execute 
only if it does not form a cycle in the graph. 

But a few important questions arise about the implementation which is typical of any multi-version 
system: (a) how many version should the STM system store? (b) which version should a transaction 
read from? 

The issue of online scheduling was analyzed in Section which partly addresses the question of 
which version should a transaction read from. Since whichever version a transaction reads from can 
possibly cause another transaction to abort, in our implementation we have decided to read the closest 
available version that does not violate mvc-opaque. Using these ideas, we are currently developing a 
new algorithm. 

To address the question on number of versions maintained, it was shown in ifTSll that by not main¬ 
taining a limit on the number of versions, greater concurrency can be achieved. So, we do not keep 
any limit on the number of versions maintained in the STM system developed. But with this approach 
the number of version keep growing over time making the system inefficient. So, a garbage collection 
strategy that removes the unwanted versions is to be designed. We are currently working on it. 

6 Conclusion 

In this paper, we have presented a new conflict notion multi-version conflict. Using this conflict notion, 
we developed a new subclass of opacity, mvc-opacity that admits multi-versioned histories and whose 
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membership can be verified in polynomial time. We showed that co-opacity, a sub-class of opacity that 
is based on traditional conflicts, is a proper subset of this class. Further, the proposed conflict notion 
mv-conflict can be applied on non-sequential histories as well unlike traditional conflicts. 

To demonstrate the effectiveness of the new conflict notion, we employed opacity, a popular correctness- 
criterion. As discussed, we believe that this conflict notion can be easily extended to other correctness- 
criterion such as LO and VWC. 

An important requirement that arises while building a multi-version STM system using the propose 
conflict notion is to decide “on the spot” or schedule online among the various versions available, which 
version should a transaction read from? Unfortunately this notion of online scheduling can sometimes 
lead to unnecessary aborts of transactions if not done carefully. To capture the notion of online schedul¬ 
ing which avoid unnecessary aborts in STMs, we have identified a new concept ols-pemiissiveness. We 
show that it is impossible for a STM system that is permissive to avoid such un-necessary aborts i.e. 
satisfy ols-permissiveness w.r.t opacity. We show this result is true for mvc-opacity as well. 

Actually, multi-version conflict notions have been proposed for multi-version databases as well 0. 
But in their model of histories, the authors do not specify which version a transaction reads. So it is 
not clear how their model will be applicable to STM histories. Moreover, their notion of conflicts were 
applicable only for sequential histories. 

As a part of the ongoing work, we plan to develop an efficient STM system using the mv-conflicts 
and measure the cost of the implementation. 
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